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Exchanging  Material  Safety  Data  Sheets 
via  Electronic  Data  Interchange: 

A  Prototype 


Executive  Summary 


An  electronic  environment  offers  significant  advantages  over  paper-based 
processes.  For  the  handlers  and  users  of  hazardous  materials  these  advantages 
include  reducing  data  duplication,  avoiding  redundant  processing,  and  moving 
information  faster  to  the  people  who  need  it.  To  test  the  feasibility  of  electronic 
processing  to  manage  material  safety  data  sheets,  we  designed  a  prototype  sys¬ 
tem.  The  prototype  enables  a  manufacturer  or  supplier  to  transmit  a  material 
safety  data  sheet  to  the  Navy's  processing  focal  point  using  electronic  data  inter¬ 
change;  to  automatically  parse  the  document  and  append  it  to  a  prototype  data 
base;  and  to  link  Navy  procurement  activities  to  the  data  base  electronically. 

Two  Navy  procurement  activities  and  two  manufacturers  participated  in  the 
test,  along  with  the  Navy's  focal  point. 

The  test  indicates  that  electronic  data  interchange  is  a  viable  medium  for 
transmitting  material  safety  data  sheets,  and  that  their  transmitted  data  can  be 
electronically  stored,  reproduced,  and  manipulated  to  support  queries,  analysis, 
and  management  reporting.  Based  upon  the  test,  we  recommend  that  the  Navy 
use  electronic  data  interchange  as  a  vehicle  for  transmitting  material  safety  data 
sheets  and  convert  its  paper-based  processing  of  them  to  a  fully  electronic  sys¬ 
tem. 


In  support  of  that  recommendation,  we  also  recommend  that  the  Navy  do 

the  following: 

♦  Use  the  fully  structured  version  of  the  Accredited  Standards  Committee 
X12  848  transaction  set,  since  it  allows  the  most  detailed  parsing  of  data. 

♦  Fully  evaluate  the  prototype  system  to  determine  desirable  changes  to  the 
functionality  that  it  provides. 

♦  Aggressively  seek  out  trading  partners  to  exchange  material  safety  data 
sheets  via  electronic  data  interchange. 

♦  Review  the  Federal  Acquisition  Regulations,  Federal  Standard  313,  Code  of 
Federal  Regulations,  and  relevant  Department  of  Defense  and  Navy  policy 
documents  to  identify  changes  that  should  be  pursued  in  order  to  process 
material  safety  data  sheets  electronically. 


iii 


♦  Analyze  existing  and  emerging  hazardous  material  management  informa¬ 
tion  systems  to  determine  their  requirements  and  enable  the  material  safety 
data  sheet  processing  system  to  interface  with  them. 

♦  Explore  other  technologies  and  standards  that  may  permit  the  Navy  to 
move  to  an  electronic  process  faster  than  by  relying  on  electronic  data  inter¬ 
change  alone. 

These  steps  will  ensure  a  smoother  path  to  realizing  the  advantages  of  an 
electronic  system. 
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Chapter  1 


Project  Overview 


Background 

In  May  1994,  the  Logistics  Management  Institute  (LMI)  completed  a  study  of 
the  Navy's  process  for  managing  material  safety  data  sheets  (MSDSs).  As  a  re¬ 
sult  of  that  study,  we  determined  that  the  process  delayed  access  to  MSDSs  for 
many  hazardous  material  (HAZMAT)  items  until  long  after  the  item  had  been 
received  —  posing  a  threat  to  safety.  An  outdated  processing  architecture  is  the 
main  factor  delaying  access  to  MSDSs.  Without  the  aid  of  an  electronic  linkage, 
three  geographically  dispersed  Navy  activities  involved  in  the  process  communi¬ 
cate  inefficiently  —  exchanging  MSDSs,  through  the  U.S.  mail,  on  paper  or  disk¬ 
ettes. 

To  remedy  these  inefficiencies,  LMI  recommended  that  the  Navy  use  an 
electronic  processing  architecture  that  exploits  existing  telecommunications  ca¬ 
pabilities  in  conjunction  with  the  use  of  electronic  data  interchange  (EDI)  tech¬ 
nologies.  An  electronic-based  environment  offers  significant  advantages  over 
the  existing  paper-based  process,  including  reducing  data  replication,  redundant 
processing,  and  the  time  required  to  make  MSDSs  available  to  the  people  who 
need  them  —  HAZMAT  handlers  and  users.  The  Navy  agreed  with  our  recom¬ 
mendations  and  directed  us  to  develop  a  prototype  system  to  test  the  feasibility 
of  MSDS  processing  in  an  electronic  environment. 


Project  Summary 

LMI  conferred  with  the  Pollution  Prevention  Office  within  the  Naval  Supply 
Systems  Command  and  the  Navy  Environmental  Health  Center,  the  Navy's  focal 
point  for  MSDS  processing,  to  define  the  functional  requirements  of  the  proto¬ 
type  system.  The  primary  requirements  were  to 

♦  transmit  electronic  MSDSs, 

♦  store  and  manipulate  MSDS  data, 

♦  provide  Navy  procurement  activities  with  read-only  access  to  the  MSDS 
data  base,  and 

♦  build  in  the  capability  to  expand  beyond  the  prototype  volume. 
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Accordingly,  the  prototype  system  was  designed  to  enable  a  manufacturer 
or  supplier  of  hazardous  materials  to  transmit  an  MSDS  to  the  Navy's  focal  point 
using  EDI.  Once  received  by  the  focal  point,  the  EDI  transaction  is  automatically 
parsed  and  appended  to  the  prototype  data  base  residing  at  the  focal  point. 
Navy  procurement  activities  participating  in  the  prototype  may  be  electronically 
linked  to  the  prototype  data  base;  they  may  then  query  the  data  base  at  any  time 
to  determine  whether  an  MSDS  is  already  resident  and,  if  so,  preclude  duplicate 
transmission. 

The  EDI  transaction  complies  with  the  fully  structured.  Accredited  Stan¬ 
dards  Committee  (ASC)  X12  848  implementation  convention  LMI  developed  un¬ 
der  separate  tasking.  LMI  designed  the  prototype  data  base  in  Microsoft  Access 
Basic,  after  evaluating  several  commercial  off-the-shelf  software  products  and  re¬ 
jecting  them  due  to  their  inability  to  perform  the  required  functions.  The  data 
base  is  capable  of  expansion  well  beyond  the  capacity  required  if  the  system 
were  implemented  Navy-wide.  LMI  also  developed  software  that  enables  any 
manufacturer  or  supplier  to  quickly  and  easily  convert  a  paper  material  safety 
data  sheet  to  an  electronic  file  in  a  format  acceptable  for  EDI. 

Two  Navy  procurement  activities  and  two  manufacturers  agreed  to  partici¬ 
pate  in  the  prototype.  The  Navy  activities  are  the  Fleet  Industrial  Support  Center 
(FISC)  Puget  Sound  and  FISC  Norfolk.  The  manufacturers  are  Chevron  in  Rich¬ 
mond,  Calif.,  and  Symtron  Systems,  Inc.,  in  Fair  Lawn,  N.J.  Chevron  manufac¬ 
turers  and  sells  multiple  FIAZMAT  products  to  FISC  Puget  Sound,  while 
Symtron  Systems,  Inc.  manufactures  only  one  product  that  it  sells  to  FISC  Nor¬ 
folk. 


Results  and  Future  Direction 

MSDS  information  was  successfully  transmitted  from  both  manufacturers  to 
the  focal  point  data  base,  proving  that  EDI  is  a  viable  medium  for  electronic 
transmission  of  this  data.  The  transmitted  MSDSs  were  successfully  appended  to 
the  prototype  data  base,  proving  that  an  electronically  transmitted  manufactur¬ 
er's  MSDS  can  be  electronically  stored  and  reproduced;  and  the  data  may  be  ma¬ 
nipulated  to  support  queries,  analysis,  and  management  reporting. 

Having  proven  the  feasibility  of  processing  MSDSs  in  an  electronic  environ¬ 
ment,  the  Navy  needs  to  develop  a  strategy  for  employing  this  capability  in  the 
near-  to  mid-term,  and  in  the  long-term  HAZMAT  management  environments. 

In  the  near-  to  mid-term,  decisions  must  be  made  about  tailoring  Federal 
Acquisition  Regulation  and  Navy  policy  requirements,  and  the  responsibilities 
and  requirements  of  MSDS  processing  activities,  to  accommodate  operations  in 
an  electronic  rather  than  a  paper-based  environment.  Additionally,  the  Navy 
must  expand  electronic  processing  to  include  as  many  manufacturers  and 
suppliers  as  possible. 
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In  the  long  term,  the  Navy  must  decide  how  the  MSDS  management  system 
will  interact  with  the  DoD  hazardous  materials  management  system  of  the  fu¬ 
ture. 

The  strategy  and  issues  related  to  processing  material  safety  data  sheets  in 
an  electronic  environment  are  further  discussed  in  Chapter  4. 


Organization  of  the  Report 

Chapter  2  describes  the  prototype  system  for  Navy  processing  of  MSDSs, 
Chapter  3  provides  results  of  the  prototype  testing,  and  Chapter  4  provides  rec¬ 
ommendations  concerning  the  prototype  system.  Appendix  A  contains  the  func¬ 
tional  requirements  statement  LMI  prepared  to  guide  the  development  of  the 
prototype  system.  Appendix  B  provides  the  project  implementation  schedule  for 
developing  the  prototype  system. 
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Chapter  2 

Description  of  Prototype 


The  previous  chapter  presented  a  high-level  look  at  the  project  background, 
summarized  the  concept,  and  briefly  described  the  results.  This  chapter  further 
describes  concepts  and  elements  basic  to  this  study. 


Concept  of  Operations 

The  primary  objective  of  this  prototype  was  to  validate  the  concept  of  using 
EDI  to  exchange  MSDSs  between  trading  partners  and  the  Navy.  In  any  effort 
implementing  EDI,  however,  it  is  essential  to  examine  the  current  business  proc¬ 
esses  and  identify  potential  areas  of  improvement.  EDI  provides  the  greatest 
benefits  to  organizations  that  seek  to  incorporate  its  capabilities  into  their  busi¬ 
ness  processes. 

In  the  near  term,  however,  the  bulk  of  the  MSDSs  submitted  to  the  focal 
point  will  be  in  hard  copy  form.  Because  of  this,  the  Navy  should  choose  an  evo¬ 
lutionary  strategy  that  will  allow  the  focal  point  to  accept  MSDSs  in  several  me¬ 
dia  forms.  Figure  2-1  illustrates  the  processing  architecture  selected  for  use  in 
this  prototype,  which  will  permit  an  evolutionary  migration  from  all  paper  to  all 
electronic  processing. 
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Focal  point 
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^  / 


Data  base 
File  server 


Floppy 
"disk 
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Figure  2-1. 

Prototype  Concept  of  Operations 
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The  centerpiece  of  this  architecture  is  the  focal  point  network  (FPN).  The 
network  consists  of  a  communications  gateway  and  application  software  run¬ 
ning  on  a  file  server  located  at  the  Navy  Environmental  Health  Center  (NEHC). 
The  focal  point  network  would  run  on  the  existing  local  area  network  at  NEHC 
to  provide  access  for  the  various  NEHC  employees  using  client  PCs.  The  FPN 
provides  the  functionality  necessary  to  receive  material  safety  data  sheets  in 
structured1  EDI  format,  share  the  data  with  others  on  the  network,  and  eventu¬ 
ally  export  the  data  to  a  data  entry  system  that  is  compatible  with  the  Hazardous 
Material  Information  System.  The  network  can  also  include  any  contractor  serv¬ 
ices  employed  for  the  manual  input  of  hard-copy  MSDSs. 

In  the  prototype  scenario,  purchasing  would  identify  the  material  require¬ 
ment  and  solicit  the  bids  in  a  manner  consistent  with  current  processing.  Instead 
of  automatically  collecting  the  MSDS  for  a  hazardous  materials  purchase,  how¬ 
ever,  the  purchasing  contracting  officer  (PCO)  would  query  the  data  base  at  the 
FPN  to  determine  whether  that  specific  MSDS  had  already  been  submitted  from 
a  previous  purchase.  If  the  MSDS  is  already  in  the  Navy  system,  the  PCO  can 
award  the  contract  without  further  MSDS  processing. 

If  a  query  shows  that  an  MSDS  is  not  in  the  Navy  system,  the  PCO  would  re¬ 
quest  the  apparently  successful  offeror  to  submit  the  MSDS  to  NEHC.  (To  satisfy 
the  Defense  Federal  Acquisition  Regulation  (DFAR),  a  hard-copy  MSDS  must 
also  be  submitted  to  the  procurement  activity.)  A  contractor  who  is  EDI-capable, 
as  in  the  case  of  Manufacturer  "A"  in  Figure  2-1,  would  then  send  an  electronic 
MSDS  to  NEHC,  either  directly  (as  shown  in  Figure  2-1)  or  through  a  value- 
added  network  (VAN).  The  PCO  could  then  verify  that  an  MSDS  was  submitted 
by  performing  another  query  of  the  FPN.  Other  contractors,  represented  as 
Manufacturer  "B"  in  Figure  2-1,  would  continue  to  submit  MSDSs  in  hard  copy. 


Elements  of  the  Prototype 

This  section  provides  further  detail  about  the  individual  elements  and  par¬ 
ticipants  in  the  prototype. 


Focal  Point  Network 

As  mentioned  above,  the  focal  point  network  is  the  centerpiece  of  the  im¬ 
proved  processing  architecture.  The  network  in  concept  is  simply  a  means  to 
link  NEHC,  the  contractor,  and  eventually  other  Navy  activities  to  a  common 
data  set.  This  serves  two  functions.  First,  it  permits  parallel  processing  of  MSDS 
data,  which  can  greatly  speed  the  document  flow,  particularly  if  other  Navy 
"value-adding"  organizations  are  included,  such  as  the  Ships  Parts  Control  Cen¬ 
ter  and  Naval  Material  Transportation  Office.  Second,  it  would  permit  efficient 


’There  are  three  different  implementation  conventions  (ICs)  widely  recognized  as 
potential  vehicles  for  sending  MSDSs  via  EDI.  The  structured  IC  makes  maximum  use  of 
codes  and  data  parsing,  and  is  used  primarily  for  automated  input  into  a  data  base. 
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resource  allocation.  NEHC  employees  would  be  able  to  handle  any  electronic 
workload  internally  while  routing  hard-copy  MSDSs  to  the  contractor  for  data 
entry  and  screening. 

Physically,  the  FPN  consists  of  many  components,  two  of  which  are  ad¬ 
dressed  in  detail  below:  the  application  software  and  the  EDI  software. 


Application  Software  (PLASMA) 

The  software  to  be  used  as  the  Navy  MSDS  data  base  represents  the  single 
most  important  element  of  the  prototype.  It  consists  of  an  import  interface  inte¬ 
grated  with  a  data  base  for  MSDS  storage.  Characteristics  of  the  application  soft¬ 
ware  include: 

♦  The  ability  to  accept  structured  EDI  material  safety  data  sheets,  fully  auto¬ 
mating  the  process  of  data  entry. 

♦  The  ability  to  review  an  inbound  electronic  MSDS  for  accuracy  and  quality 
prior  to  addition  to  the  main  data  base.  This  includes  the  ability  to  check  for 
duplicate  MSDS  submissions  based  upon  manufacturer,  part  number,  and 
MSDS  date  of  preparation. 

♦  "Upgradability"  to  include  adding  the  capability  to  import  semistructured 
or  unstructured  EDI  transactions,  plain  American  Standard  Code  for  Infor¬ 
mation  Interchange  (ASCII)  text  files,  and  scanned  (optical  character  recog¬ 
nition,)  MSDSs. 

♦  Graphical  user  interface  data  entry  screens  to  speed  processing  of  hard-copy 
MSDSs. 

♦  Networking  capability  to  allow  multiple  access  to  stored  records  and  simul¬ 
taneous  data  entry. 

♦  Export  capability  to  a  variety  of  different  application  formats,  including  the 
dBase  (.dbf)  format  consistent  with  the  "floppy  build"  program  currently 
used  to  interface  with  HMIS. 

♦  True  relational  data  storage,  resulting  in  increased  storage  efficiency,  data 
integrity,  and  query  capability. 

Because  the  Navy's  process  of  MSDS  processing  is  not  duplicated  in  private 
industry,  and  because  EDI  has  not  yet  been  established  as  a  dominant  method 
for  exchanging  MSDSs,  commercial  off-the-shelf  MSDS  software  with  those  char¬ 
acteristics  does  not  exist.  Appendix  A  provides  a  detailed  description  of  the  cri¬ 
teria  used  in  formulating  a  "make  versus  buy"  decision. 

We  developed  the  Prototype  Long-Range  Automated  System  for  MSDS 
Management  (PLASMA)  as  a  Microsoft  Access  data  base  application.  It  is  a 
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Windows  file  with  the  file  extension  of  MDB  (i.e.,  PLASMA.MDB).  The  data 
base  file  contains  not  only  the  MSDS  tables,  but  the  screens,  reports,  and  unique 
programs  as  well.  The  application  can  be  executed  in  either  of  two  different 
ways,  as  Figure  2-2  illustrates: 


Full  Microsoft  Access  Program 


Figure  2-2. 

Run  Time  vs.  Full  Program 


MSAGCESS.EXE  is  the  executable  file  that  comes  with  the  full  version  of  Mi¬ 
crosoft  Access.  It  allows  users  to  not  only  run  all  applications  but  create  and 
modify  those  applications  as  well.  MSARN200.EXE  is  the  run-time  version  of 
Microsoft  Access.  If  the  developer  of  the  data  base  application  (e.g., 
PLASMA.MDB)  purchases  the  Microsoft  Access  Developer's  Toolkit,  as  we  did, 
that  developer  may  freely  distribute  the  run-time  version  of  Access  along  with 
the  application.  In  this  case,  if  the  Navy  decides  to  purchase  the  Developer's 
Toolkit,  the  run-time  version  of  PLASMA  could  be  freely  distributed  to  procure¬ 
ment  activities  or  trading  partners.  If  users  wish  to  purchase  a  full  version  of  Mi¬ 
crosoft  Access,  the  Navy  can  freely  distribute  the  PLASMA.MDB  data  base  file, 
and  users  can  run  PLASMA  from  the  regular  program.  Using  either  method,  we 
are  confident  that  the  DFAR  clause  252.227-7013,  Rights  in  Technical  Data  and 
Computer  Software  (Oct  1988),  gives  the  government  authority  for  such  use. 

PLASMA  operates  on  an  IBM-compatible  personal  computer.  Because  of  the 
numerous  calculations  performed  by  PLASMA  during  any  given  operation,  the 
PC  should  preferably  be  a  high-speed  486-class  (or  higher)  unit  with  at  least 
12  megabytes  of  random  access  memory.  In  addition,  a  17-inch  high-resolution 
monitor  is  necessary  for  those  who  would  use  PLASMA  for  daily  editing  or  re¬ 
trieval  of  MSDSs. 


EDI  Software  (Translator) 

In  addition  to  application  software,  processing  EDI  transactions  requires  the 
use  of  EDI  software,  often  referred  to  as  a  translator.  The  translator  serves  two 
basic  functions.  For  inbound  transactions,  a  translator  converts  the  ANSI 
ASC  X12-compliant  transaction  sent  by  a  trading  partner,  in  this  case  an 
ASC  X12.36  848  Material  Safety  Data  Sheet,  into  a  format  that  is  recognizable  by 
the  user's  application  software.  This  format  is  referred  to  as  a  user-defined  file 
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(UDF).  For  outbound  transactions,  the  translator  performs  the  reverse  process. 
It  converts  the  outgoing  UDF  provided  by  the  application  software  into  an  ANSI 
ASC  X12-compliant  EDI  transaction.  These  processes  are  both  represented  in 
Figure  2-3. 
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Figure  2-3. 

Data  Flow  in  MSDS  Electronic  Transfer 


In  order  to  perform  these  functions,  the  translator  must  have  a  "mapping  so¬ 
lution"  that  defines  how  the  application  software  data  appear  in  the  inbound  or 
outbound  UDF.  For  this  project,  a  mapping  solution  has  been  developed  to  meet 
the  requirements  of  the  MSDS  data  base  application  software.  The  mapping  so¬ 
lution  and  translator  selected  for  use  in  the  prototype,  while  PC-based,  are  con¬ 
sistent  with  the  Navy  and  Defense  Information  Systems  Agency  (DISA)  standard 
(Sterling  Software/ABC  GENTRAN  Excel).  For  operational  use,  after  the  proto¬ 
type,  the  mapping  solution  can  and  should  be  converted  to  a  UNIX-based  plat¬ 
form. 


Other  Prototype  Elements 

Additional  elements  of  the  prototype  include  entities  external  to  the  focal 
point  network.  These  entities  include  Navy  activities  participating  in  the  project, 
commercial  trading  partners,  and  communication  services  such  as  a  value-added 
network. 


NAVYAcnvmES 


As  previously  described  in  this  chapter  under  "Concept  of  Operations,"  the 
procurement  contracting  officer  may  be  given  the  ability  to  access  the  data  base 
remotely  to  determine  whether  there  is  an  MSDS  record.  This  can  be 
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accomplished  through  the  use  of  remote  control  software,  which  allows  the  PCO 
to  "take  control"  of  a  client  PC  at  the  FPN  and  query  for  an  MSDS. 

Several  procurement  activities  assisted  us  in  testing  the  prototype  concept. 
These  included  Portsmouth  Naval  Ship  Yard,  Norfolk  Fleet  Industrial  Support 
Center,  Naval  Surface  Warfare  Center  (Crane,  Ind.),  and  Puget  Sound  Fleet  In¬ 
dustrial  Support  Center.  We  contacted  representatives  from  each  activity,  de¬ 
scribed  the  concept,  and  asked  the  representative  to  provide  us  with  a  sample  list 
of  their  hazardous  material  suppliers.  We  then  contacted  those  suppliers  to  so¬ 
licit  interest  in  participating. 


Trading  Partners 


Trading  partners  were  selected  from  a  list  of  potential  candidates  that  each 
procurement  activity  provided.  We  attempted  to  select  trading  partners  as  rep¬ 
resentatives  from  the  population  of  Navy  contractors.  This  population  includes 
large,  multinational  corporations  as  well  as  small  manufacturers  and  retail  estab¬ 
lishments.  In  addition,  the  degree  of  experience  with  and  exposure  to  electronic 
commerce  varies  widely  within  the  population.  The  two  trading  partners  who 
agreed  to  participate  are  Chevron,  USA,  Inc.,  headquartered  in  San  Francisco, 
and  Symtron  Systems,  Inc.,  of  Fair  Lawn,  N.J. 

Chevron,  as  a  large  manufacturer  of  petroleum  products,  has  an  established 
corporate  information  system  and  electronic  data  interchange  program.  Most  of 
Chevron's  information  is  processed  on  a  mainframe-level  platform  that  includes 
its  repository  of  MSDSs.  Chevron  implemented  its  EDI  program  several  years 
ago  at  the  request  of  a  large  customer  but  has  never  exchanged  material  safety 
data  sheets  using  EDI.  Mr.  Steve  Bosso,  of  Chevron  Information  Technology  Di¬ 
vision,  has  led  the  effort  necessary  to  extract  the  MSDS  data  from  the  mainframe, 
structured  in  the  ANSI  Z400.1  format,  and  convert  it  to  an  electronic  MSDS  con¬ 
sistent  with  the  structured  X12  848. 

Symtron  Systems  is  a  small  manufacturer  (less  than  100  employees)  of  fire¬ 
fighting  training  equipment  and  supplies.  Symtron  provides  the  Navy  with  a 
product  used  in  dispersing  smoke  resulting  from  shipboard  fires,  purchased  pri¬ 
marily  through  FISC  Norfolk.  Symtron  has  no  established  corporate  information 
system  other  than  individual  IYZs,  and  had  no  previous  exposure  to  EDI.  Sym- 
tron's  MSDSs  are  in  hard  copy  and  were  developed  prior  to  the  establishment  of 
the  ANSI  Z400.1  Standard  for  Hazardous  Industrial  Chemicals  -  Material  Safety  Data 
Sheet  Preparation.  We  have  provided  Symtron  with  the  software  and  training 
necessary  to  implement  an  EDI  program  for  exchanging  MSDSs. 


Value-Added  Network 

A  value-added  network  can  provide  the  networking  necessary  to  link  trad¬ 
ing  partners  along  with  various  services  to  enhance  EDI  exchanges.  For  the  pur¬ 
poses  of  trading  with  a  large  company  with  many  trading  partners,  such  as 
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Chevron,  a  VAN  is  a  necessity  and  was  used  in  the  prototype.  Conversely,  a 
VAN  may  not  be  necessary  when  trading  with  Symtron,  which  currently  has  no 
other  trading  partners.  This  applies  only  to  the  transaction  volume  expected 
during  a  prototype,  however. 

The  operational  scenario  would  use  a  VAN  for  all  trading  partners  as  well 
utilizing  the  Navy  and  DISA  communications  architecture  and  translation  assets. 
Instead  of  linking  directly  to  the  VAN,  NEHC  would  retrieve  an  MSDS  in  the 
form  of  a  user-defined  file  from  a  regional  translator,  currently  referred  to  as  a 
DISA  EDI  Gateway.  This  DISA  EDI  Gateway  receives  files  from  a  DISA  Net¬ 
work  Entry  Point  which,  in  turn,  retrieves  the  file  from  the  VAN.2 


2  For  a  complete  description  of  the  Navy  and  DISA  EDI  architecture,  refer  to  the  Navy 
Strategic  Plan  for  Electronic  Data  Interchange,  May  1995. 
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Chapter  3 


Project  Results 


Two  manufacturers  successfully  transmitted  MSDS  information  to  the  focal 
point  data  base,  proving  that  EDI  is  a  viable  medium  for  exchanging  such  infor¬ 
mation.  This  chapter  provides  an  overview  of  both  the  mechanics  of  data  trans¬ 
fer  and  considerations  in  prototype  development. 


Observations  on  the  Process 


This  section  describes  the  processing  required  on  the  part  of  the  sender  and 
the  receiver. 


Manufacturer  Storage  of  MSDSs 

Chevron  stores  its  MSDS  information  as  text  files  residing  on  a  mainframe 
computer.  A  Chevron  programmer  used  a  data  base  programming  language 
(NOMAD2)  to  extract  the  data  in  a  "flat  file"  or  "user-defined  file"  format.  Be¬ 
cause  the  source  was  a  simple  text  document,  he  created  a  program  that  ex¬ 
tracted  the  file  and  parsed  the  data  based  upon  content.  This  provided  the  data 
discipline  necessary  for  sending  the  structured  version  of  the  ASC  X12  848. 

The  parsed  flat  file  was  then  routed  to  the  corporate  translator  via  job  con¬ 
trol  language  (JCL)  for  conversion  into  ASC  X12  848  format.  Translation  and  file 
transfer  to  the  VAN  was  automated,  and  the  process  from  flat  file  extraction  to 
EDI  file  receipt  in  the  Navy's  VAN  mailbox  took  less  than  15  minutes. 

Chevron's  programmer  indicated  that  the  effort  required  approximately 
four  man-months  of  analysis  and  programming.  Most  of  this  time  was  dedi¬ 
cated  to  creating  the  parsing  program  necessary  to  convert  the  text  into  a  struc¬ 
tured  transaction.  While  this  represented  a  unique  challenge,  the  programmer 
was  greatly  aided  by  two  factors.  First,  Chevron's  MSDSs  are  consistent  with  the 
American  National  Standards  Institute  (ANSI)  Z400.1  Standard  for  Hazardous  In¬ 
dustrial  Chemicals  -  Material  Safety  Data  Sheet  Preparation.  Second,  Chevron  has 
an  established  EDI  program,  which  allowed  the  programmer  to  concentrate  on 
flat  file  generation.  In  general,  many  of  the  Navy's  larger  trading  partners 
would  likely  find  a  similar  experience. 

The  Navy  also  purchases  significant  quantities  of  hazardous  material  from 
smaller  trading  partners,  however.  A  small  company's  information  processing 
generally  requires  no  more  than  a  PC,  or,  increasingly,  PCs  supported  by  a  net¬ 
work.  In  the  case  of  Symtron  Systems,  Inc.,  we  provided  the  software  necessary 
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for  electronic  storage.  Commercial  off-the-shelf  software  is  available  for  MSDS 
management  by  PC.  It  is  not  known,  however,  how  many  Navy  trading  partners 
currently  manage  a  material  safety  data  sheet  as  a  record  in  a  data  base  manage¬ 
ment  program,  as  a  word  processing  file,  or  as  a  hard  copy.  In  any  case,  the 
process  of  data  extraction  and  conversion  to  electronic  data  interchange  is  suffi¬ 
ciently  difficult  to  surpass  the  programming  capabilities  of  most  smaller  compa¬ 
nies. 


As  the  need  for  this  process  increases,  through  increased  demand  for  elec¬ 
tronic  MSDSs,  it  is  likely  that  off-the-shelf  software  will  address  the  requirement. 
In  the  short  term,  however,  most  trading  partners  would  rely  on  a  value-added 
service  to  convert  their  data  into  an  electronic  data  interchange  format. 


Data  Transfer  and  Download 

As  indicated.  Chevron  used  an  automated  process  for  translation  and  file 
transfer  to  its  VAN,  which  in  this  case  was  General  Electric  Information  Systems' 
EDPEXPRESS  Service.  We  agreed  to  use  the  same  VAN  to  avoid  charges  from 
third-party  interconnect  services.  EDI*EXPRESS  Service  is  also  one  of  the  largest 
service  providers. 

Before  data  transfer  could  take  place  within  the  VAN,  a  trading  partnership 
had  to  be  set  up  with  Chevron.  Both  parties  identify  their  interchange  qualifiers 
and  party  names  to  the  VAN,  as  shown  in  Figure  3-1.  When  the  VAN  receives 
an  ASC  X12  transaction,  the  system  finds  the  ISA  (interchange  control  header) 
segment  and  identifies  the  sending  party  in  ISA06  ("CHEVMSDS"  in  this  case) 
and  the  receiving  party  in  ISA08  ("USNEHC"  for  the  U.S.  Navy  Environmental 
Health  Center).  This  concept  differs  slightly  from  the  concept  of  a  fixed  "mail¬ 
box."  Instead  of  a  fixed  address,  as  in  E-mail  messaging  protocols,  these  names 
can  vary  with  any  and  all  trading  partnerships  established,  as  long  as  the  VAN 
knows  what  aliases  each  party  will  use. 


ISA06  (Sender's  name)  ISA08  (Receiver's  name) 


ISA\00\  \00\  \ZZ\CHEVMSDS  \ZZ\USNEHC  \950504\ 

1 246\U\00300\000000005\Q\T\~ 

GS\MS\CHEVMSDS\USNEHC\950504\1246\5\X\003050 

ST\848\500000001 

BMS \00\93040 7\EN\0005 13\1 5 

DTM\102\930407 

N1\MF\CHEVRON  USA  PRODUCTS  COMPANY\1\D&BNUMBER 

- {MSDS  Detail} 

SE\23A50000000 1 
GE\1\5 

IEA\im0000005 

Figure  3-1. 

ASC  X12  848  Transaction 
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Upon  verbally  confirming  with  Chevron  that  it  had  sent  an  MSDS,  we  ac¬ 
cessed  the  VAN  via  a  local  telephone  number  using  a  modem  and  a  communica¬ 
tions  software  package.  After  logging  on  and  providing  our  password,  we 
accessed  the  data  transfer  menu  and  confirmed  that  our  mailbox  had  one  (or 
more)  messages.  Upon  command,  the  system  bundled  the  messages  (if  more 
than  one)  into  a  single  file  and  awaited  our  data  transfer  command.  Using  the 
XMODEM  file  transfer  protocol  and  a  transmission  rate  of  9600  baud,  a  single 
MSDS  took  less  than  40  seconds  to  download  from  the  VAN  to  our  PC. 

In  the  operational  scenario,  NEHC  would  not  interact  with  the  VAN  di¬ 
rectly.  The  administrator  of  the  regional  translator  would  be  responsible  for  han¬ 
dling  most  of  the  trading  partner  and  VAN  connect  and  interconnect  issues,  as 
well  as  administering  batch  access  to  the  VAN.  NEHC  would  have  to  coordi¬ 
nate,  however,  with  the  administrator  of  the  regional  translator  to  determine  fre¬ 
quency  of  data  access  and  availability,  particularly  if  a  purchase  were  being  held 
up  pending  MSDS  submission. 


VAN  Service  and  Cost 

The  VAN  service  proved  to  be  reliable,  if  not  completely  intuitive  or  user- 
friendly.  The  basic  procedures,  once  learned,  were  quick  and  easy  to  execute. 
We  did  have  some  trouble  interpreting  the  download  file  if  it  had  been  bundled 
from  more  than  one  input  file.  While  the  translator  can  accept  bundled  transac¬ 
tions,  the  application  will  not.  Our  solution  was  to  manually  unpackage  the  file 
into  individual  transaction  files  using  a  text  editor. 

Because  of  the  extremely  light  mailbox  volume  we  expected,  we  selected  a 
billing  plan  with  a  smaller  fixed  fee  and  a  relatively  high  variable  cost  based  on 
kilocharacter  throughput.  The  typical  MSDS  is  approximately  15  kilocharacters 
in  length,  which  equates  to  roughly  $4.50  per  document  received.  The  actual  rate 
applicable  to  the  Navy  will  be  much  smaller  based  upon  discounts  and  billing  at 
operational  volumes.  The  sender  pays  a  similar  fee  based  upon  its  own  billing 
plan. 


Translation 


After  a  file  had  been  downloaded  from  the  VAN  into  a  specified  directory 
on  our  computer,  we  then  converted  the  EDI  transaction  into  our  user-defined 
file  specification  using  the  translator.  The  translator  proved  to  be  reliable,  and 
the  mapping  solution  seemed  to  be  robust.  We  experienced  minor  difficulties 
initially  with  the  interpretation  of  the  implementation  convention,  but  we  re¬ 
solved  these  by  simple  modifications  to  the  mapping  solution.  Because  the 
translator  can  maintain  a  mapping  file  for  each  trading  partner,  this  increases 
flexibility  and  can  be  used  to  fine-tune  for  trading  partner  differences.  Figure  3-2 
illustrates  part  of  a  user-defined  file  resulting  from  translation. 
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ChevOI  0100040793000513  0015  040793 

ChevOI  02MFCHEVRON  USA  PRODUCTS  COMPANY  1  D&BNUMBER  ENVIRONMENTAL,  SAFETY,  & 
ChevOI  05MGCPS2161XX 
ChevOI  17  1.00C12 

ChevOI  18SECTION  1.00;CHEMICAL  PRODUCT  AND  COMPANY  IDENTIFICATION  FOR  :  100%  JET  FUEL 
- {MSDS  Detail} 

ChevOI  18SECTION  16.00;DISCLAIMER  FOR :  100%  JET  FUEL 

ChevOI  18THE  ABOVE  INFORMATION  IS  BASED  ON  THE  DATA  OF  WHICH  WE  ARE  AWARE  AND  IS  BELIEVED 


Figure  3-2. 

Typical  User-Defined  File  (UDF) 


Record  Upload 

The  translator  creates  a  fixed-length  flat  file  that  the  PLASMA  application 
program  uses  to  upload  the  record  into  the  data  base.  Microsoft  Access  has  a 
built-in  import  application  for  reading  fixed-length  files  based  upon  a  specifica¬ 
tion  the  user  provides.  A  significant  amount  of  programming  in  Access  Basic 
was  required,  however,  to  fully  automate  the  process  of  populating  all  the  re¬ 
lated  tables. 

During  the  upload  process,  a  single  file  is  selected  for  import  into  the  appli¬ 
cation.  Because  of  the  complex  queries  and  record  generation  programming  exe¬ 
cuted,  a  typical  MSDS  takes  approximately  15  seconds  to  fully  populate  the 
designated  tables. 


General  Observations 

The  technology  and  process  proved  viable  and  efficient  for  populating  a 
trading  partner's  data  base  with  an  electronic  MSDS.  The  entire  process,  from 
data  extraction  to  data  receipt  and  uploading  by  the  Navy,  could  occur  in  less 
than  15  minutes.  This  represents  an  enormous  improvement  in  time  and  re¬ 
sources  compared  with  current  processing. 

Chevron  has  also  demonstrated  the  feasibility  of  converting  a  text  file  into  a 
structured  transaction.  Its  program  solves  the  fundamental  problem  of  incom¬ 
patible  data  storage  methods  by  bridging  the  gap  between  text  files  and  data 
base  records.  Smaller  companies,  however,  do  not  have  the  programming  or  EDI 
resources  available  to  support  such  programming.  A  low-cost  solution  exists  in 
the  form  of  a  service  provider  who  will  convert  a  trading  partner's  document 
into  an  ASC  X12  transaction. 

A  better  solution  will  become  available  when  low-cost  software  for  MSDS 
management  supports  a  structured  EDI  transaction.  This  is  not  likely  to  occur, 
however,  until  the  need  is  created  by  large  customers,  such  as  the  Navy,  requir¬ 
ing  electronic  MSDSs. 
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Relational  Data  Base 


A  relational  MSDS  data  base  demonstrated  that  automation  provides  a  sig¬ 
nificant  advantage  over  a  mechanical  process.  Specifically,  the  data  base  pro¬ 
vides  a  wide  range  of  functional  utility  to  the  focal  point,  including  the 

following: 

♦  Establishing  a  relational  data  base  design  that  will  improve  MSDS  data  qual¬ 
ity 

♦  Automating  the  input  of  MSDSs  into  the  focal  point  data  base 

♦  Reducing  focal  point  operating  costs  by  limiting  manual  data  entry 

♦  Checking  that  a  new  MSDS  transaction  is  not  already  in  the  existing  master 
data  base  prior  to  acceptance 

♦  Managing  a  wide  variety  of  MSDS  transactions,  including  structured,  semis- 
tructured,  and  unstructured  EDI  formats,  other  text  formats,  scanned  text, 
and  hard  copy 

♦  Facilitating  data  entry  for  those  MSDS  transactions  that  are  not  already  in 
the  existing  master  data  base 

♦  Facilitating  the  review  and  editing  of  data  already  in  the  master  data  base 

♦  Facilitating  the  printing  of  entire  MSDS  documents  in  a  format  suitable  for 
quick  reference  and  display,  should  a  hard  copy  be  necessary 

♦  Providing  a  user-friendly  means  to  conduct  both  predefined  and  ad  hoc 
queries  against  the  master  data  base 

♦  Providing  the  basis  to  export  MSDS  data  electronically  to  an  HMIS- 
compatible  format,  either  on-line  or  via  floppy  disk. 

We  present  our  findings  on  some  of  these  points  in  more  detail  below 


MSDS  Hierarchy 

The  hierarchical  relationship  of  data  within  an  MSDS  is  not  formally  defined 
by  existing  regulations  and  policies.  While  the  absence  of  a  hierarchical  structure 
provides  broad  flexibility  in  preparing  an  MSDS,  a  relational  data  base  requires 
that  the  hierarchical  structure  of  data  be  precisely  defined.  Consequently,  we 
were  forced  to  infer  the  hierarchical  relationship  of  MSDS  data.  We  did  this  by 
reviewing  Federal  Standard  313  (which  identifies  MSDS  data  requirements),  the 
ANSI  Z400.1  standard,  and  a  sample  of  actual  MSDSs  prepared  by  various 
manufacturers  using  different  formats. 
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The  prototype  data  base  reflects  the  inferred  relational  hierarchy  for  the 
MSDS  data  transmitted  by  EDI  transaction.  The  relational  hierarchy  is  estab¬ 
lished  by  parsing  the  MSDS  data  to  various  tables  and  linking  each  of  the  tables 
to  one  or  more  tables  through  key  fields  resident  in  each  of  the  linked  tables. 
Figure  3-3  shows  the  entity  relationship  diagram  for  the  prototype  data  base. 


Table  of  Table  of  Table  of 


Ji 


Table  of 
ingredients 

CAGE  Code 
Supplier's  Part  Number 
Date  of  Preparation 
Registry 
Number 
Composition  % 

General  Hazard  Desc. 
OSHA  PEL  (TWA) 
OSHA  PEL  (Ceiling) 
ACGIH  TLV  (short  term) 
ACGIH  TLV  (TWA) 
Exposure  Units  of  Meas. 
Suppliers  Recommend. 


Other  Sections  Tabte 

Section  Number 
Section  Ovmrimv 
Topic  Heading 
Tope  Text 


Legend: 

One-to-many  relationship 
in  direction  of  arrow 
One-to-one  relationship 
in  direction  of  arrow 


t? 


[Section  15,  Regulatory  information 

E:tion  14,  Transport  Information 
tion  9,  Physical  Properties 


Section  5,  Firefighting  Measures 
Section  Overview 
Rash  Point  and  UoM 
Test  Method 

Autoignkion  Temp  and  UoM 
Autodocomposrtron  Temp  and  UoM 


lulatory  Topics 
[Transport  Topics 
Physical  Properties  Topics 
R relighting  Topics 
Section  Overview 
Topic  Heading 
Topic  Text 


Note:  Fieds  in  italics  represent  table  keys. 


Figure  3-3. 

Entity  Relationship  Diagram 


The  table  containing  manufacturers'  data  is  at  the  head  of  the  hierarchical 
structure.  A  single  manufacturer  identified  by  CAGE  code  may  be  linked  to  one 
or  more  products  identified  by  supplier's  part  number.  Each  product  may  be 
linked  to  one  or  more  MSDSs,  the  most  current  MSDS  on  file  and  previous  MSDS 
submissions,  as  distinguished  by  the  date  of  preparation.  An  MSDS  may  be 
linked  to  one  or  more  ingredients  identified  by  the  Chemical  Abstract  Services  or 
National  Institute  of  Occupational  Safety  and  Health  number  and  also  to  each 
section  of  the  MSDS  identified  by  section  number. 

For  design  purposes,  the  sections,  as  defined  by  the  ANSI  Z400.1  standard, 
can  be  classified  as  following  one  of  several  patterns.  The  first  pattern  is  that  of  a 
section  header  followed  by  one  or  more  subsections,  with  each  subsection  having 
one  or  more  topics  and  related  information  or  warnings.  We  were  able  to  create 
a  single  table  to  incorporate  each  of  these  sections  as  a  one-to-many-relationship 
with  the  main  MSDS  record.  The  other  sections  (Section  5,  Firefighting  Meas¬ 
ures,  for  example)  do  not  follow  a  consistent  pattern,  and  we  created  separate 
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tables  for  each  of  these  four  sections.  We  set  these  tables  up  as  a  one-to-one  rela¬ 
tionship  with  the  main  MSDS  record,  as  indicated  in  Figure  3-3. 

The  use  of  one-to-many  relationships  affords  significant  flexibility  in  accept¬ 
ing  various  MSDS  formats,  provided  the  MSDS  is  at  least  loosely  based  upon  the 
ANSI  Z400.1  standard.  Conversely,  any  table  or  field  that  is  "hardcoded"  into 
the  design  restricts  this  flexibility.  For  any  future  application  based  upon  this 
design,  we  would  recommend  further  use  of  the  one-to-many  relationships  be¬ 
tween  tables.  For  example,  in  Figure  3-3,  the  emergency  contact  fields  should  be 
moved  from  the  table  of  manufacturers  into  a  separate  table  using  a  many-to-one 
relationship  with  the  table  of  manufacturers.  Similarly,  the  exposure  fields  in  the 
table  of  ingredients  should  be  set  up  as  a  separate  table  with  a  many-to-one  rela¬ 
tionship  with  the  table  of  ingredients.  In  this  way  the  application  could  accept 
any  number  of  emergency  contact  references  (or  exposure  guidelines)  instead  of 
a  predefined  limit  of  five,  for  example. 

MSDSs  submitted  by  the  manufacturers  that  participated  in  the  prototype 
testing  fit  neatly  into  the  hierarchical  relationship  established  by  the  prototype 
data  base.  Flowever,  lacking  a  standard  for  preparing  MSDSs  prior  to  the  devel¬ 
opment  of  the  ANSI  Z400.1,  manufacturers  and  vendors  have  more  than  likely 
created  hierarchical  structures  for  their  MSDSs  and  included  data  fields  that  can¬ 
not  be  accommodated  by  the  prototype  data  base.  The  prototype  test  did  not  re¬ 
veal  this  problem  since  it  involved  only  two  manufacturers.  This  potential 
problem  will  be  resolved  only  by  the  universal  endorsement  of  acceptable  data 
fields  and  a  hierarchical  standard. 


Logic  Diagram  for  Appending  New  MSDSs 

Our  review  of  the  procedure  for  determining  the  uniqueness  of  each  MSDS 
submitted  to  the  Navy's  processing  focal  point  revealed  that  it  was  performed 
manually  and  that  it  keyed  on  the  following  three  data  points: 

♦  Supplier's  part  number 

♦  Supplier's  CAGE  code 

♦  Date  of  preparation  of  MSDS. 

The  data  base  performs  this  function  automatically  according  to  the  logic  in  Fig¬ 
ure  3-4. 
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Figure  3-4. 

MSDS  Verification  Logic 


The  data  base  accepts  the  supplier's  part  number  as  transmitted  and  stores  it 
as  "supplier's  part  number."  It  also  removes  nonsignificant  characters  such  as 
"Mil  Spec"  and  stores  the  data  as  "stripped  part  number."  Finally,  it  standard¬ 
izes  any  nonsignificant  characters,  adds  those  standardized  characters  to  the  sig¬ 
nificant  characters  of  the  part  number,  and  stores  the  data  as  "refined  part 
number."  This  process  assists  part  number  searches  by  eliminating  the  need  to 
know  how  the  manufacturer  or  supplier  constructs  its  part  numbers.  The  data 
base  also  allows  storage  of  three  additional  supplier  part  numbers. 

In  addition  to  precluding  the  appending  of  duplicate  MSDSs  to  the  data 
base,  this  logic  diagram  also  eliminates  the  need  to  append  manufacturer  data,  if 
the  manufacturer  has  previously  submitted  an  MSDS  for  one  of  its  hazardous 
products,  or  product  data,  if  a  previous  version  of  the  product's  MSDS  with  the 
same  part  number  had  been  submitted. 

The  data  base  was  not  populated  with  data  prior  to  first  receipt  of  MSDSs 
from  manufacturers  that  participated  in  the  prototype  test.  Consequently,  all 
EDI-transmitted  MSDSs  were  accepted  by  the  data  base.  To  test  the  ability  of  the 
data  base  to  screen  out  duplicate  data,  we  attempted  to  reappend  the  previously 
accepted  MSDSs,  and  the  data  base  appropriately  indicated  that  the  manufactur¬ 
ers,  products,  and  MSDSs  were  already  resident. 

The  supplier  part  numbers  submitted  by  the  manufacturers  during  the  pro¬ 
totype  test  did  not  contain  nonsignificant  characters,  so  the  data  base  stored  the 
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same  part  number  as  both  the  "stripped  part  number"  and  the  "refined  part 
number."  None  of  the  submitted  MSDSs  contained  more  than  three  additional 
supplier  part  numbers,  so  the  data  base  accommodated  the  transmitted  part 
number  data. 


Printing  MSDSs 

The  ability  to  print  MSDSs  from  the  data  base  is  provided  by  the  report  writ¬ 
ing  feature  of  the  Microsoft  Access  software.  We  created  a  report  shell  for  the 
prototype  based  upon  the  ANSI  Z400.1  standard.  When  the  MSDS  print  function 
is  selected,  data  for  the  selected  MSDS  automatically  populates  the  shell,  and  the 
MSDS  can  then  be  viewed  on  the  screen  or  printed. 

Because  of  the  lack  of  standardization  and  actual  quantity  of  data  contained 
in  each  MSDS,  the  report  display  program  is  one  of  the  most  complex  operations 
the  application  performs.  Many  calculations  determine  the  existence  or  absence 
of  data  in  each  section  and  subsection,  seriQusly  taxing  the  report  generating  ca¬ 
pabilities  of  Microsoft  Access.  On  a  PC  configured  with  a  486-100  MHz  micro¬ 
processor  and  16  megabytes  of  RAM,  the  process  of  displaying  an  MSDS  took 
approximately  50  to  60  seconds. 

Because  the  application  will  support  links  to  external  objects,  an  alternative 
or  supplement  to  generating  a  standardized  report  could  be  referencing  an  elec¬ 
tronic  image  for  each  MSDS  record.  After  an  MSDS  has  been  imported  into  the 
data  base,  NEHC  personnel  could  scan  an  image  of  the  manufacturer's  MSDS 
and  attach  a  link  to  the  image  file  in  the  data  base.  Anyone  desiring  to  see  an  im¬ 
age  of  the  actual  MSDS  could  do  so  with  a  single  click  of  the  mouse  button.  This 
would  combine  the  data  management  capabilities  of  the  data  base  with  the  secu¬ 
rity  of  maintaining  a  true  image  of  the  trading  partner's  MSDS. 


Network  Processing 

The  prototype  concept  envisions  that  activities  involved  in  processing 
MSDSs  can  remotely  access  the  data  base  to  query  records,  and  view  or  down¬ 
load  data.  The  focal  point  data  base  system  can  run  as  a  host  so  that  an  activity 
with  a  computer,  a  modem,  and  remote  control  software  can  remotely  operate 
the  focal  point  computer  to  perform  selected  functions. 

This  function  was  not  actually  tested  during  the  prototype  operation,  but  us¬ 
ing  a  host  computer  from  a  remote  site  with  commercially  available  software  is  a 
well-established  practice.  The  only  unresolved  issue  regarding  network  process¬ 
ing  is  the  number  of  activities  that  should  be  given  access  to  the  focal  point  data 
base.  Resolving  this  issue  will  determine  the  computer  processing  requirement. 
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The  Current  Environment 


In  our  search  for  viable  trading  partners,  we  encountered  over  50  manufac¬ 
turers  and  vendors  in  varying  stages  of  information  automation.  Their  enthusi¬ 
asm  at  the  prospect  of  conducting  business  electronically  was  unanimous.  They 
quickly  recognized  and  embraced  the  potential  benefits  of  reduced  paperwork 
and  increased  speed  of  contract  award.  Most  expressed  interest  in  participating 
in  the  prototype. 

In  contrast  to  their  enthusiasm  was  the  reality  that  few  manufacturers  and 
vendors  knew  much  about  EDI,  and  some  did  not  use  computers  in  their  busi¬ 
ness  process  at  all.  Many,  however,  did  use  automated  data  processing  tools  ex¬ 
tensively,  but  did  not  use  EDI.  The  few  that  used  EDI  tended  to  be  the  very 
large  corporations  where  the  marginal  startup  cost  of  an  EDI  program  was  triv¬ 
ial,  and  where  economies  of  scale  yielded  quick  paybacks.  Finally,  none  were  ex¬ 
changing  MSDS  information  via  the  ASC  X12  848  implementation  convention 
developed  by  the  joint  PIDX/  CIDX  committee. 

In  the  next  several  years,  however,  government  contractors  will  come  under 
increasing  pressure  to  conduct  business  electronically.  As  of  the  date  of  this  re¬ 
port,  the  implementation  conventions  using  the  ASC  X12  848  are  being  consid¬ 
ered  for  adoption  as  Federal  guidelines  by  the  Federal  Standards  Committee. 
Because  the  MSDS  business  process  is  closely  associated  with  the  procurement 
process,  it  is  likely  to  be  incorporated  into  a  new,  reengineered  electronic  process 
using  EDI.  At  that  point,  trading  partner  enthusiasm  for  exchanging  MSDSs  via 
EDI  should  increase  dramatically. 

Although  EDI  is  a  viable  and  efficient  medium  for  exchanging  MSDS  infor¬ 
mation,  it  is  some  time  away  from  maturing  into  the  industry  method  of  choice. 
Indeed,  the  Navy's  trading  partner  base  represents  a  wide  variety  of  technologi¬ 
cal  capabilities,  many  not  yet  sophisticated  enough  to  use  EDI.  The  Navy  should 
endeavor  to  accommodate  that  range  and  grow  along  with  it.  EDI  is  one  method 
to  exchange  MSDS  information  that  is  destined  to  gain  market  share  as  transla¬ 
tion  software  and  VAN  costs  decrease,  and  the  Navy  needs  to  include  it  in  its 
portfolio  of  electronic  exchange  options. 
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Chapter  4 


Recommendations 


Electronic  Processing 

We  recommend  that  the  Navy  use  EDI  as  a  vehicle  for  the  electronic  trans¬ 
mission  of  MSDSs,  and  that  it  pursue  a  strategy  for  converting  the  current  paper- 
based  MSDS  processing  system  to  a  fully  electronic  one. 

Two  of  the  largest  industry  groups  involved  with  the  manufacture  and  dis¬ 
tribution  of  hazardous  materials  (PIDX/CIDX)  have  reached  consensus  on  the 
formats  for  exchanging  MSDS  data  using  EDI.  They  are  the  unstructured,  semis- 
tructured,  and  fully  structured  versions  of  the  ASC  X12  848  transaction  set.  Of 
the  three  implementation  conventions  developed  by  PIDX/CIDX,  the  fully  struc¬ 
tured  ASC  X12  848  allows  the  most  detailed  parsing  of  data.  That  feature  per¬ 
mits  the  fullest  application  of  data  base  management  capabilities,  including 
queries,  management  reporting,  and  data  export  to  other  automated  systems  that 
require  hazardous  material  management  data  input.  For  that  reason,  we  recom¬ 
mend  use  of  the  fully  structured  format  to  the  greatest  extent  possible. 


Program  Management 

The  Navy  must  approach  further  implementation  of  electronic  MSDS  proc¬ 
essing  with  a  well-defined  strategy  which  ensures  evolution  consistent  with 
Navy  and  trading  partner  capabilities  and  requirements.  We  recommend  the 
Navy  formally  establish  responsibility  for  the  development  of  this  program. 
Close  coordination  is  required  among  many  organizations,  internal  and  external 
to  DoD,  and  functional  areas,  especially  procurement.  In  addition,  many  techni¬ 
cal  issues  remain  which  must  be  addressed  before  the  Navy  can  pursue  full-scale 
implementation.  We  address  some  of  these  issues  in  this  chapter. 


Software 


While  the  system  developed  for  the  purpose  of  the  prototype  can  accommo¬ 
date  current  transaction  volumes,  we  recommend  that  the  Navy  fully  evaluate 
the  prototype  system  to  determine  additions,  deletions,  or  modifications  to  its 
features.  In  addition,  the  Navy  should  consider  process  changes,  user  volumes, 
and  data  volume  before  attempting  to  implement  a  fully  operational  electronic 
system  for  MSDS  collection  and  data  distribution.  Based  on  that  evaluation,  the 
Navy  should  develop  a  detailed  requirements  list  and  request  competitive  bids 
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to  develop  software  with  the  desired  features.  Suggested  functional  improve¬ 
ments  which  both  PLASMA  and  Microsoft  Access  can  support  include: 

♦  External  object  reference  to  scanned  images  of  the  manufacturer's  MSDS 

♦  Automating  the  check  for  duplicate  MSDSs  and  for  the  presence  of  manda¬ 
tory  data 

♦  Increased  flexibility  in  data  base  design  through  greater  use  of  one-to-many 
table  relationships 

♦  Exporting  user-defined  files  for  the  purpose  of  sending  intra-DoD  struc¬ 
tured  MSDSs. 


Hardware  and  Communications 

Before  the  Navy  can  begin  accepting  electronic  MSDSs,  the  Navy  must  first 
satisfy  the  basic  hardware  requirements  and  establish  the  communications  path 
necessary  to  conduct  electronic  commerce.  These  requirements  include: 

♦  Establishing  a  host  PC  for  the  data  base  application  (PLASMA).  PLASMA  re¬ 
quires  a  486-class  PC  (or  better)  with  at  least  12  megabytes  of  RAM  and  a 
17-inch  high  resolution  monitor. 

♦  Implementing  a  local  area  network  (LAN)  at  NEHC.  This  will  permit  multiple 
users  access  to  a  common  data  set  and  allow  for  parallel  processing  of  MSDS 
records. 

♦  Establishing  a  communications  path.  This  can  be  as  simple  as  attaching  a  mo¬ 
dem  with  a  dedicated  telephone  line  to  the  host  PC. 

♦  Acquiring  translation  services.  For  continued  development  of  this  prototype, 
we  recommend  using  the  Navy's  own  test  and  development  gateways  for 
translation,  communication,  and  trading  partner  registration.  For  the  fully 
operational  scenario,  however,  the  Navy  must  coordinate  with  DISA  for 
these  services. 


Soliciting  Trading  Partner  Participation 

We  recommend  that  the  Navy  aggressively  seek  out  trading  partners  who 
are  willing  and  able  to  exchange  MSDSs  using  EDI.  The  Navy  should  evaluate 
potential  procurement  sites  based  on  MSDS  volumes,  existing  EDI  capabilities, 
and  relationships  with  selected  commercial  trading  partners.  It  should  enlist  the 
support  of  major  trading  partners  in  encouraging  the  use  of  electronic  commerce 
throughout  their  respective  procurement  and  distribution  chains. 
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The  Navy  should: 


♦  Use  trade  journals,  workshops,  and  other  public  forums  to  publicize  the 
benefits  of  using  EDI  to  exchange  MSDS  information 

♦  Integrate  the  material  safety  data  sheet  into  the  procurement  process,  using 
the  contracting  mechanism  as  a  tool  to  encourage  the  use  of  electronic  com¬ 
merce 

♦  Offer  financial  incentives  (e.g.,  lowest  bid  +x%)  for  participation 

♦  Brief  buyers  so  that  they  may  encourage  contractors  with  whom  they  do 
business  to  participate. 

Because  many  Navy  trading  partners  must  overcome  the  hurdle  of  structur¬ 
ing  a  text,  or  even  hardcopy,  MSDS,  the  Navy  should  encourage  technologies 
which  can  overcome  this  problem.  The  Navy  should  also  encourage  manufac¬ 
turers  and  vendors  to  use  service  organizations  that  would  convert  supplier 
MSDS  records  into  electronic  data  bases. 

Finally,  establish  an  "MSDS  center"  and  a  toll-free  number  to  advise  and  as¬ 
sist  interested  companies  on  how  to  participate  in  this  program. 


Overcoming  Barriers  to  Implementation 

Current  policies  and  procedures  were  designed  to  regulate  a  paper-based 
process.  To  fully  realize  the  benefits  of  electronic  MSDS  processing,  certain  poli¬ 
cies  and  procedures  need  to  be  modified.  We  recommend  that  the  Federal  Ac¬ 
quisition  Regulation  (FAR),  Federal  Standard  313,  Code  of  Federal  Regulations, 
and  DoD  and  Navy  policy  documents  related  to  MSDS  processing  be  reviewed 
to  identify  changes  that  should  be  pursued  in  order  to  process  material  safety 
data  sheets  in  an  electronic  architecture. 

The  Navy's  MSDS  processing  system  of  the  future  must  interface  with  exist¬ 
ing  and  emerging  Navy  and  Office  of  the  Secretary  of  Defense  (OSD)  systems. 
We  recommend  that  the  Navy  conduct  an  analysis  to  determine  interface  re¬ 
quirements  of  other  systems  and  build  those  requirements  into  the  MSDS  proc¬ 
essing  system. 
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Prototype  Expansion 


As  the  concept  of  distributing  MSDS  data  becomes  more  mature,  the  Navy 
should  consider  a  scheme  that  best  leverages  its  advantages.  To  the  prototype 
one  would  add 


♦  a  requisition  filtering  mechanism,  in  an  attempt  to  reduce  the  use  of  hazard¬ 
ous  materials  when  the  requirement  is  identified, 

♦  a  central  translation  gateway,  to  limit  systemwide  programming  and  main¬ 
tenance  costs. 


♦  and  an  electronic  commerce  procurement  relationship  that  speeds  and  sim¬ 
plifies  the  contract  award  process.  This  expanded  implementation  is  de¬ 
picted  in  Figure  4-1. 


NEHC 


tSmm 

/  Qualify  control 


>  \ 


>.  / 


Read-write 


Contractor 


'\M. 


Manual  data  entry 
screening  P/Ns 


Figure  4-1. 

Expanded  Implementation 


To  the  expanded  implementation,  one  would  add  the  concept  of  truly  dis¬ 
tributing  MSDS  data  electronically.  The  goal  is  to  collect  it  once,  never  rekey, 
perpetuate  the  data  through  the  hazardous  materials  life  cycle,  and  give  diverse 
users  access  to  the  information  they  need.  This  fully  integrated  method  of  col¬ 
lecting,  managing,  and  using  MSDS  data  is  depicted  in  Figure  4-2. 
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Manufacturer 


Figure  4-2. 

Full  Implementation 

Supplemental  Technical  Opportunities 

While  EDI  has  been  proven  as  an  efficient  and  reliable  vehicle  for  the  ex¬ 
change  of  material  safety  data  sheets,  other  forms  of  electronic  exchange  should 
be  studied  for  feasibility.  Several  other  emerging  technologies  and  standards 
may  permit  a  more  diversified  portfolio  of  methods  for  exchanging  electronic 
documents.  Electronic  data  interchange  still  offers  the  Navy  the  most  utility  for 
populating  an  automated  data  base,  but  based  upon  trading  partners'  capabili¬ 
ties  and  source  document  storage  methods,  these  other  technologies  and  stan¬ 
dards  may  permit  the  Navy  to  move  to  an  electronic  process  faster  than  by 
relying  on  EDI  alone. 

1.  Standard  Generalized  Markup  Language  (SGML).  SGML  provides  interesting 
opportunities  for  document  storage  and  transfer.  In  contrast  to  EDI,  which 
focuses  on  business  transactions,  SGML's  strength  lies  in  storing  and  retriev¬ 
ing  reference  materials,  such  as  technical  drawings.  When  trading  partners 
use  a  common  document  type  definition1  (DTD),  they  can  exchange  docu¬ 
ments  electronically  with  markups  that  define  not  only  what  information 
the  document  contains  but  exactly  how  it  looks  as  well.  Fonts,  spacing, 
point  size,  and  other  layout  characteristics  in  the  DTD  permit  the  document 
to  be  identically  reproduced  at  the  receiving  trading  partner's  data  base. 
Additionally,  a  repository  of  documents  using  SGML  tags  can  duplicate 
some  functions  of  a  data  base,  such  as  conditional  querying.  SGML  does 
face  some  of  the  same  obstacles  to  implementation  as  EDI,  however.  These 
obstacles  include  both  the  hardware  (a  high-end  PC)  and  software  necessary 
to  set  up  an  SGML  workstation.  In  addition,  a  common  or  de  facto  DTD 
must  be  established  for  MSDSs,  and  because  SGML  is  so  relatively  new  to 


1 A  DTD  is  an  agreement  between  trading  partners  for  the  use  of  an  SGML  document. 
It  is  analogous  to  an  EDI  implementation  convention  (IC). 
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the  business  community,  it  may  be  several  years  before  an  accepted  format 
is  adopted  and  used,  if  ever.  Still,  the  Navy  should  explore  the  potential  for 
using  SGML  to  augment  its  data  collection  processes. 

2.  ASCII  or  pure  text  transfer.  An  MSDS  stored  as  a  word  processing  text  file 
represents  the  lowest  common  denominator  in  electronic  exchange  and  re¬ 
trieval.  Many  organizations  store  material  safety  data  sheets  as  electronic 
documents  created  using  commercial  word  processing  software.  These 
documents  can  easily  be  converted  to  ASCII,  essentially  making  them 
software-independent.  The  converted  document  can  then  be  forwarded  to 
the  Navy  via  Internet,  for  example,  using  one  of  the  common  methods  such 
as  file  transfer  protocol  or  simple  mail  transfer  protocol. 

The  more  difficult  task,  however,  is  reducing  this  undisciplined  data  into 
the  discreet  tables  and  elements  used  by  the  DoD  for  MSDS  storage.  One 
proven  method  is  to  cut  and  paste  the  data  into  appropriate  locations  within 
the  data  base.  While  somewhat  time-consuming,  the  method  perhaps  offers 
advantages  over  strict  data  entry. 

An  alternative  is  to  explore  the  feasibility  of  using  a  "parsing  engine"  pro¬ 
gram.  The  parsing  engine  searches  an  ASCII  document  looking  for  key¬ 
words  that  match  section  headings  and  discreet  elements  within  sections. 
With  some  intervention,  the  parsing  engine  can  somewhat  automate  the  task 
of  cutting  and  pasting  by  identifying  how  the  data  should  be  segregated. 
Because  of  the  wide  variety  of  MSDS  formats  being  used,  the  existing  ver¬ 
sions  of  parsing  engines  we  have  seen  demonstrated  are  crude  at  best.  As 
the  range  of  different  MSDS  formats  converge  in  the  near  future,  however, 
the  concept  may  prove  viable. 

3.  Optical  character  recognition  (OCR)  scanning.  As  technology  improves,  OCR 
scanning  may  become  a  more  viable  method  of  MSDS  input.  The  current 
generation  of  scanners  are  still  dependent  upon  the  original  document  con¬ 
dition  and  require  error  detection  and  correction  after  input.  While  scan¬ 
ning  can  potentially  speed  the  process  of  data  input,  the  document  is  still 
transferred  via  fax  or  mail.  Image  scanning,  not  OCR,  can  perhaps  augment 
another  form  of  transfer,  such  as  EDI,  by  providing  an  accompanying  pic¬ 
ture  of  the  document. 

All  of  the  methods  listed  can  help  to  increase  the  Navy's  ability  to  quickly 
and  accurately  process  MSDSs  while  relying  on  fewer  external  resources.  The 
Navy  should  not  seek  to  choose  a  single  technology  or  method,  as  they  are  all 
complementary.  EDI  has  made  the  most  progress  to  date  toward  moving  MSDSs 
electronically  between  trading  partners  and  also  offers  the  Navy  the  most  utility 
in  the  form  of  cost  savings.  Other  methods,  including  those  mentioned,  may  of¬ 
fer  added  capability  at  marginal  cost  and  should  be  studied  accordingly. 
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Appendix  A 


Feasibility  Study 


This  portion  of  the  report  was  written  at  the  onset  of  the  project  and  reflects  the 
analysis  performed  prior  to  development  of  the  prototype.  It  is  meant  to  provide  insight 
into  the  development  process,  but  because  it  reflects  information  prior  to  actual  develop¬ 
ment,  it  does  not  contain  recommendations  regarding  any  part  of  the  Navy  hazardous 
materials  program. 


Preliminary  Analysis 

Problem  Definition  and  Opportunity 

The  Navy's  focal  point  receives  material  safety  data  sheets  (MSDSs)  only  in 
hardcopy  format.  As  a  result,  personnel  must  process  a  large  quantity  of  paper 
and  expend  significant  resources  performing  data  entry.  The  word  processing 
application  used  is  very  basic  and  allows  only  for  minimum  use  of  automation. 
In  addition,  data  transfer  between  focal  point,  subfocal  points,  and  external  par¬ 
ties  is  entirely  by  mail.  The  resulting  process  is  slower  and  more  resource¬ 
intensive  than  necessary. 

Converting  this  process  to  an  electronic  one  with  more  sophisticated  soft¬ 
ware  and  data  management  techniques  could  save  both  time  and  money.  Spe¬ 
cifically,  use  of  the  ASC  X12  848  MSDS  between  Navy  trading  partners  and  the 
focal  point  would  eventually  result  in  near-complete  automation. 

Other  emerging  technologies  may  facilitate  the  Navy's  ability  to  capture 
data  electronically  instead  of  by  paper.  Use  of  Standardized  General  Markup 
Language  (SGML)  may  allow  the  Navy  personnel  to  further  manipulate  or  struc¬ 
ture  text  files  into  data  base-compatible  files  with  a  minimum  of  effort. 


Overall  Objectives 

Our  primary  objective  is  to  establish  a  working  prototype  of  a  system  capa¬ 
ble  of  capturing  electronic  MSDSs  submitted  by  Navy  trading  partners.  While  a 
typical  prototype  may  only  validate  a  concept,  we  intend  to  pursue  this  as  an 
evolutionary  system  which  could  become  the  focal  point's  primary  method  of 
data  collection,  editing,  and  eventual  submission  to  Hazardous  Material  Infor¬ 
mation  System  (HMIS).  For  the  purpose  of  this  project,  our  concept  of  a  "sys¬ 
tem"  is  generally  limited  to  a  standalone  software  package. 
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Specific  characteristics  of  the  system  should  include  the  ability  to: 

♦  Network  and  share  data  among  geographically  dispersed  activities. 

♦  Significantly  reduce  the  requirement  for  manual  manipulation  of  data. 

♦  Support  DoD  and  Navy's  goals  of  moving  to  the  integrated  Hazardous  Sub¬ 
stance  Management  System  (HSMS). 

♦  Interface  with  as  large  a  segment  of  the  Navy  trading  partner  population  as 
economically  feasible. 

♦  Significantly  decrease  the  time  required  to  process  MSDSs  into  HMIS- 
compatible  format. 

The  accomplishment  of  these  objectives  are  beyond  the  scope  of  this  project.  We 
are  instead  seeking  to  provide  the  Navy  with  a  system  which  can  be  expanded 
upon,  improved,  and  used  as  a  means  toward  fulfilling  these  goals. 

System  Users 

The  system  may  eventually  be  networked  to  include  other  facilities,  but  the 
primary  users  will  be  the  focal  point  personnel.  In  all  likelihood,  however,  the 
limited  resources  available  to  the  focal  point  may  instead  require  installation  at 
the  contractor's  facility.  Ideally,  both  locations  would  be  setup.  The  politics  of 
this  present  some  risk,  and  we  may  have  to  approach  this  from  several  direc¬ 
tions. 


Data  Flow  Diagram 

In  this  example.  Figure  A-l,  the  high-level  data  flows  are  shown.  There  are 
at  least  two  paths  from  trading  partner  to  focal  point  (not  including  hard  copy). 
Currently  the  data  will  leave  the  focal  point  only  in  the  form  of  a  floppy  disk  to 
HMIS. 

Figure  A-2  details  data  flow  at  the  focal  point  to  include  alternate  forms  of 
data  capture,  including  direct  entry  into  the  word  processing  (or  text  editor)  por¬ 
tion  of  the  system.  The  front-end  receives  incoming  data,  passes  it  to  the  word 
processing  application  for  manipulation  and  quality  control.  The  data  should 
leave  the  word  processing  in  HMIS-compatible  format.  That  is,  the  data  ele¬ 
ments  and  attributes  should  be  consistent  with  those  of  the  HMIS  data  base 
structure.  Depending  upon  mode  of  entry,  each  record  will  require  little  to  sig¬ 
nificant  formatting. 
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Trading  partner 


Procurement 


Figure  A-1. 

Level  0  Data  Flow  Diagram  (Macro  Level) 


Navy  Focal  Point 


Figure  A-2. 

Level  1  Data  Flow  Diagram  (Focal  Point  Level) 


Figure  A-3  illustrates  the  basic  purpose  of  the  front-end  which  is  to  receive 
the  incoming  file  from  a  translator  or  other  communications  source,  provide 
some  structure  to  the  data,  and  hold  until  required  by  the  word  processing  appli¬ 
cation.  Ideally  the  system  could  also  sort  duplicates  and  adds  by  comparing 
header  information. 
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Figure  A-3. 

Level  2  Logic  for  Front-End 


The  data  is  passed  from  the  front-end  to  the  word  processing  application  ei¬ 
ther  as  a  structured,  parsed  data  file,  or  as  a  generally  unstructured,  text-only 
file.  In  the  case  of  the  latter,  the  word  processing  would  hold  the  text  file  while 
the  system  imposes  previously  defined  structure,  in  the  form  of  SGML  or  other 
parsing  logic,  to  the  document.  Further  manipulation  to  any  file  prepares  the  re¬ 
cord  for  export  in  an  HMIS-compatible  format. 


Incoming  MSDS 


No 


? 


Apply  SGML  to 
parse  data 

~E= 

QC  and  edit 
to  format  for 
HMIS  app. 


Output  as  floppy  disk; 
record  copied  to  file 


Figure  A-4. 

Level  2  Logic  for  Word  Processing  Application 
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Primary  Analysis 


Proposed  Archtiecture 

We  propose  operating  the  system  on  a  486-class  PC  which  would  serve  as 
the  data  base  linked  to  a  network  of  local  PC's  of  similar  power,  each  capable  of 
running  the  application  locally.  We  believe  distributed  processing  techniques  of¬ 
fer  the  most  efficient  use  of  computing  resources.  The  file  server  could  also  serve 
as  the  telecommunications  gateway  for  access  by  other  networks,  such  as  one 
running  at  a  subfocal  point.  This  gateway  would  also  serve  as  the  recipient  of 
electronic  records  submitted  by  trading  partners.  As  trading  partner  participa¬ 
tion  increases,  more  processing  power  may  be  required,  and  the  communications 
module  and  data  base  management  system  may  have  to  reside  on  separate  plat¬ 
forms. 

The  primary  network  operated  at  the  focal  point  would  permit  efficient 
workflow  among  those  individuals  adding  value,  screening,  or  performing  edits. 
Records  ready  for  added  value  from  another  network  could  be  batch  down¬ 
loaded  through  the  gateway  to  the  subfocal  point. 

Several  communication  issues  must  be  resolved  prior  to  implementation. 
Generally  these  issues  are  beyond  the  scope  of  this  document.  The  most  notable 
exception,  however,  is  that  of  translation  software.  The  status  of  translation  as¬ 
sets  is  currently  in  a  state  of  flux. 


Make  or  Buy  Analysis 

Purchasing  a  system  represents  the  quickest,  easiest,  and  Iowest-risk  solu¬ 
tion  to  satisfying  minimum  user  requirements.  However,  based  upon  our  re¬ 
quirements  and  desired  system  capabilities,  finding  a  commercial  package 
meeting  all  criteria  is  unlikely.  Most  systems  address  the  requirements  of  an  em¬ 
ployer  or  manufacturer.  The  focal  point,  who  is  responsible  for  throughput,  may 
not  need  all  of  the  capabilities  provided  in  some  packages.  For  example,  most 
systems  act  as  the  repository,  a  function  served  by  HMIS  in  our  case.  Other  fea¬ 
tures  offer  capabilities  not  currently  required  by  the  focal  point  but  which  may 
provide  value  in  the  future,  such  as  environmental  management  capabilities. 

Developing  a  system  would  result  in  a  closer  match  of  requirements  and 
system  features.  There  are  serious  uncertainties  which  arise  in  attempting  to  de¬ 
velop  such  a  system,  however.  These  include  cost,  time  to  complete,  and  value 
of  end-product.  Still,  depending  upon  the  software  available  off-the-shelf,  de¬ 
velopment  may  provide  the  most  efficient  use  of  resources  and  result  in  a  close 
match  with  user  requirements.  Obtaining  a  quote  for  coding,  testing,  and  sup¬ 
port  based  upon  the  completed  version  of  the  physical  specification  is  worth  ex¬ 
ploring. 

Other  considerations  for  a  make  vs.  buy  decision  will  impact  the  acceptance 
of  the  system;  for  example,  appearance  and  usability  of  end-product. 
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Presumably  a  commercial  package  would  assign  a  premium  to  these  attributes. 
We  also  believe  that  these  attributes  will  influence  the  success  of  the  project,  and 
not  simply  from  a  functional  perspective.  A  professionally-designed  product 
that  "looks  sharp"  will  stand  in  contrast  to  many  of  the  other  applications  run  by 
the  Navy  and  will  impact  on  the  emotional  acceptance  of  the  product. 

Additional  criteria  include  reliability  and  maintainability.  Once  again,  it  is 
presumed  that  commercial  packages  would  be  rigorously  tested  and  designed  in 
a  high  level,  fourth-generation  language  which  would  facilitate  its  serviceability 
and  upgradeability. 

A  third  alternative  is  to  customize  a  commercial  package.  Depending  upon 
the  degree  of  work  required,  this  also  opens  up  issues  of  cost,  time,  and  reliabil¬ 
ity. 


Project  Risk  Analysis 

Several  issues  pose  varying  degrees  of  risk  to  both  the  short-  and  long-term 
success  of  the  project. 

♦  Electronic  data  interchange  (EDI)  may  not  gain  acceptance  or  momentum  as 
the  preferred  electronic  method  for  MSDS  submission.  While  movement  to¬ 
ward  electronic  format  seems  assured  in  the  long  term,  EDI  is  not  yet  estab¬ 
lished  as  the  overwhelming  method  of  choice. 

♦  The  PIDX/CIDX  implementation  convention  may  not  gain  wide  acceptance. 
While  there  is  a  possibility  that  a  more  fully-codified  version  may  prevail, 
the  PIDX/  CIDX  version  offers  a  degree  of  codification  which  is  consistent 
with  HMIS's  current  abilities. 

♦  We  may  encounter  hardware  requirements  which  we  did  not  anticipate.  For 
example,  we  do  not  know  what  computing  capabilities  Navy  Environmental 
Health  Center  (NEHC)  (or  anyone  else)  has.  We  may  encounter  telecommu¬ 
nications  issues  such  as  dedicated  phone  lines,  modem  availability,  or  trans¬ 
lation  assets.  Some  of  these  issues  can  be  solved  easily  and  relatively 
cheaply.  Most  others  are  probably  outside  the  scope  of  the  project  and  are 
the  Navy's  responsibility. 

♦  The  system  may  not  perform  as  advertised,  in  the  case  of  a  purchased  pack¬ 
age,  or  as  specified,  in  the  case  of  in-house  development. 

Most  of  these  risk  factors  can  be  mitigated  through  strategy  or  planning.  In 
the  first  case,  as  an  example,  we  can  explore  several  methods  of  electronic  trans¬ 
fer  or  invest  in  a  system  flexible  enough  to  accept  various  forms  of  data  import. 
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Recommendations 


The  project  is  technologically,  economically,  and  organizationally  feasible. 
Our  recommendation  is  to  proceed  ahead,  mapping  a  strategy  which  will  maxi¬ 
mize  the  potential  for  short-  and  long-term  success,  as  defined  by  our  initial  ob¬ 
jectives,  and  minimize  those  risk  factors  identified. 

Specifically,  we  need  to  identify  the  set  of  data  transfer  methods  which  will 
maximize  the  trading  partner  potential  and  make  this  a  principle  criteria  in  our 
system  selection.  Because  one  of  our  objectives  is  to  establish  a  working  proto¬ 
type  from  which  the  Navy  can  build  upon,  we  should  explore  the  use  of  alter¬ 
nate  technologies  (such  as  SGML). 

We  should  also  begin  surveying  commercial  off-the-shelf  (COTS)  as  soon  as 
possible.  This  will  provide  us  with  some  critical  information  to  include  whether 
or  not  there  is  a  package,  in  our  price  range,  which  can  generally  meet  our  mini¬ 
mum  criteria.  It  will  also  provide  us  with  a  better  understanding  of  what  capa¬ 
bilities  we  require  or  may  want  in  the  future.  Lastly,  if  we  cannot  find  an 
acceptable  commercial  package,  we  will  need  as  much  time  as  possible  to  investi¬ 
gate  our  own  system  development. 

While  we  want  to  provide  a  system  with  as  much  utility  as  possible,  we  also 
need  to  limit  the  scope  of  the  project  and  reach  an  understanding  with  the  client 
as  to  what  tasks  appropriately  fall  into  our  area  of  responsibility. 


Requirements  Analysis 

System  Inputs  and  Outputs 

The  system  will  be  accepting  inputs  from  several  of  a  potential  number  of 
sources.  These  sources  include  electronic  transfer  via  EDI,  electronic  transfer  in 
ASCH  format,  manual  data  entry,  import  from  existing  data  base,  and  scanned 
entry.  The  primary  output  will  be  the  MSDS,  in  HMIS-format,  downloaded  as  a 
floppy  disk. 

1.  Electronic  Transfer  via  EDI.  Eventually  the  Navy  should  seek  to  move  as 
much  data  as  possible  by  EDI,  primarily  because  it  provides  the  most  defini¬ 
tion  to  the  data  structure  and  can  result  in  nearly  complete  automated  proc¬ 
essing.  The  three  guidelines  currently  recognized  by  the  Navy  include  the 
unstructured,  semi-structured,  and  structured  conventions  modeled  after 
the  PIDX/ CIDX  industry  guideline.  Mapping  protocols  must  be  developed 
for  each  guideline,  although  their  location,  internal  or  external  to  the  system, 
is  yet  to  be  determined.  When  we  survey  the  COTS  we  should  gain  a  better 
understanding  of  how  programs  advertised  as  "EDI-compatible"  interface 
with  the  translation  software.  There  is  the  possibility  that  additional  pro¬ 
gramming  will  be  required  to  provide  the  bridge  from  flat  file  to  application 
program. 
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2.  Miscellaneous  Electronic  Transfer.  Many  programs  advertise  the  ability  to  im¬ 
port  data  via  "electronic  transfer."  We  need  to  understand  what  this  specifi¬ 
cally  means,  if  there  is  a  standard  definition.  In  all  probability,  it  is  the 
transfer  of  an  ASCII  file  via  modem  with  a  minimum  envelope  structure. 
Because  this  is  a  simple  form  of  data  transmission,  and  because  most  trading 
partners'  data  bases  are  set  up  as  flat  text  files,  this  mode  of  transfer  is  open 
to  a  large  segment  of  the  Navy  trading  partner  population.  While  it  does 
not  provide  much  structure  or  automation,  the  use  of  SGML  may  enhance 
its  utility  to  the  Navy  and  provide  a  "first  step"  toward  all  electronic  proc¬ 
essing. 

3.  Manual  Data  Entry.  In  the  near  term,  manual  data  entry  will  still  dominate 
as  the  practical  method  of  entering  MSDSs  into  the  system  for  HMIS- 
compatible  formatting.  Because  the  system  should  evolve  into  the  Navy's 
primary  MSDS  management  system,  it  must  provide  the  entry  screens  capa¬ 
ble  of  accepting  keyed-in  data.  Most  COTS  packages  accept  this  form  of 
data  capture. 

4.  Scanner  Entry.  Another  form  of  data  entry  is  through  the  use  of  a  digital  im¬ 
aging  processing  system.  While  a  full-fledged  imaging  system  is  relatively 
expensive,  the  hardware  necessary  to  perform  Optical  Character  Recogni¬ 
tion  scanning  is  fairly  inexpensive  (around  $1,500).  Scanning  hardcopy 
MSDSs  into  a  system  represents  an  efficiency  over  manual  data  entry,  but  it 
is  not  as  efficient  as  any  form  of  electronic  transfer.  Some  COTS  packages 
do  support  entry  by  scanning. 


Determining  System  Capacities 

Data  Volumes  and  User  Volumes 

The  current  volume  of  paper  MSDSs  to  the  focal  point  is  approximately 
40,000  (gross)  annually.  At  some  point  this  may  be  reduced  by  process  and  pol¬ 
icy  changes  that  allow  procurement  activities  to  query  for  the  preexistence  of  a 
record.  In  these  cases,  no  MSDS  would  be  required  or  submitted  to  the  focal 
point.  In  this  case,  based  upon  a  current  70%  duplication  rate,  the  inflow  may  be 
reduced  to  15,000  or  less  annually. 

User  volumes  are  harder  to  estimate.  In  an  architecture  using  distributed 
processing  techniques,  it  is  more  useful  to  estimate  using  networks  and  then  esti¬ 
mate  the  individual  users  on  each.  Initially,  we  plan  on  one  to  three  networks 
with  an  average  of  eight  users  each.  It  is  conceivable,  however,  that  the  system 
would  feed  more  than  two  dozen  facility  networks,  located  across  the  country. 
This  is  a  remote  possibility,  however,  and  is  beyond  the  scope  of  the  project. 


Appendix  B 

Schedule  for  Implementing  Prototype 


This  appendix  provides  a  work  breakdown  structure  in  the  form  of  a  Gantt 
chart  of  the  major  tasks  involved  in  the  completion  of  the  prototype.  It  incorpo¬ 
rates  the  basic  structure  of  systems  development  with  the  project  requirements 
for  any  electronic  data  interchange  (EDI)  implementation.  While  the  chart  does 
not  necessarily  reflect  actual  time  devoted  to  any  individual  task,  it  does  give  a 
general  idea  of  relative  effort  devoted  to  each  major  requirement. 
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3.1  S|>ectfy  Hardware  and  Syale 


Appendix  C 


Glossary 


asch 

American  Standard  Code  for  Information  Inter¬ 
change 

ANSI 

= 

American  National  Standards  Institute 

ASC 

= 

Accredited  Standards  Committee 

CAS 

= 

Chemical  Abstract  Services 

CFR 

= 

Code  of  Federal  Regulations 

CIDX 

= 

chemical  industry  data  exchange 

COTS 

= 

commercial  off-the-shelf  software 

DDN 

= 

Defense  Data  Network 

DFAR 

= 

Defense  Federal  Acquisition  Regulation 

DGSC 

= 

Defense  General  Supply  Center 

DISA 

= 

Defense  Information  Sytems  Agency 

DLA 

= 

Defense  Logistics  Agency 

DoDI 

= 

Department  of  Defense  Instruction 

DTD 

document  type  definition 

EDI 

=r 

electronic  data  interchange 

FAR 

= 

Federal  Acquisition  Regulation 

FISC 

= 

Fleet  Industrial  Support  Center 

FPN 

= 

focal  point  network 

FTP 

= 

file  transfer  protocol 

GUI 

= 

graphical  user  interface 
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HAZMAT 

HICS 

HMIS 

IC 

JCL 

MSDS 

NAVMTO 

NAVSUPSYSCOM 

NEHC 

NLN 

NSN 

OSD 

OCR 

OSHA 

PCO 

PIDX 

PLASMA 

RAM 

SGML 

SPCC 

SPEED 

TSES 

UDF 


=  hazardous  material 

=  Hazardous  Material  Inventory  Control  System 

=  Hazardous  Material  Information  System 

=  implementation  convention 

=  job  control  language 

=  material  safety  data  sheet 

=  Navy  Material  Transportation  Office 

=  Naval  Supply  Systems  Command 

=  Navy  Environmental  Health  Center 

=  Navy  logistics  network 

=  national  stock  number 

=  Office  of  the  Secretary  of  Defense 

=  optical  character  recognition 

=  Occupational  Safety  and  Health  Administration 

=  procurement  contracting  officer 

=  petroleum  industry  data  exchange 

=  Prototype  Long  Range  Automated  System  for 
MSDS  Management 

=  random  access  memory 

=  Standard  Generalized  Markup  Language 

=  Ships  Parts  Control  Center 

=  Standard  Processing  Environment  for  Electronic 
Documents 

=  Technical  Screening  Expert  System 
=  user-defined  file 
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USNEHC 

VAN 


=  U.S.  Navy  Environmental  Health  Center 
=  value-added  network 
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